\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{enumerate}
\usepackage{tabularx}
\usepackage{graphicx}
\usepackage{chngpage}
 \usepackage{float}
\usepackage{calc}

\title{Software Engineering}
\author{Adrian.Nembach@uni-konstanz.de 01/842319\\Udo.3.Schlegel@uni-konstanz.de 01/840835\\Sirui.Liu@uni-konstanz.de 01/857316}
\begin{document}
\maketitle

\section{Einleitung}

\subsection{Zweck}
Dieses Software Design Dokument beschreibt die Softwarearchitektur und das Systemdesign eines einfachen Onlineshops.

\subsection{Designziele}
Ziel dieses Designs ist es einen kleinen Onlineshop zur Verfügung zu stellen, der von einer einzelnen Person oder einer kleinen Gruppe von Personen betrieben werden kann. Das Design dieses Onlineshops ist für größere Unternehmen nicht geeignet! Dafür soll die Verwaltung auch ohne große Vorkenntnisse im Computerbereich möglich sein.

\subsection{Überblick}

\subsection{Definitionen und Abkürzungen}
\begin{itemize}
\item Mit System ist im allgemeinen die zugrundeliegende Software des Onlineshops gemeint.
\item Mit Betreiber ist die Person bzw. Personengruppe gemeint, die den Onlineshop betreibt.
\item Mit Kunde bzw. Kunden sind die Personen gemeint, die in diesem Onlineshop einen Benutzeraccount besitzen und Bestellungen tätigen.
\end{itemize}

\section{Vorhandene Software Architektur}
Da das System neu entwickelt werden soll, gibt es keine vorhanden Software Architektur, allerdings gibt es im Internet viele verschiedene Formen von Onlineshops, die als Vorbild dienen können.

\section{Vorgeschlagene Software Architektur}

\subsection{Überblick}
Grob betrachtet zerlegen wir das System in die fünf Subsysteme:
\begin{itemize}
\item Display
\item ProductManagement
\item UserManagement
\item OrderManagement
\item DataManagement
\end{itemize}

\subparagraph{Display}
Das Subsystem Display ist zuständig für die Anzeige der Daten und beinhaltet auch die Schnittstellen für Kunden und Betreiber.
\subparagraph{ProductManagement}
Das Teilsystem ProductManagement kümmert sich um alle wichtigen Funktionen, die sich mit den im Shop verkäuflichen Produkten befassen.
\subparagraph{UserManagement}
Dieses Teilsystem kümmert sich um die Verwaltung der Kundendaten und alle Funktionen, die sich mit Kunden befassen.
\subparagraph{OrderManagement}
OrderManagement übernimmt die Verwaltung der Bestellungen und stellt Funktionen zur Verfügung, die im Zusammenhang mit Bestellungen wichtig sind.
\subparagraph{DataManagement}
DataManagement bildet die Schnittstelle zur zu Grunde liegenden Datenbank.

\subsection{Teilsystemzerlegung}
\includegraphics[scale=0.5]{Subsystems.jpg}
\subsubsection{Component Diagram}

\includegraphics[scale=0.4]{Components.jpg}


\subsubsection{Komponenten - intern}



Von den oben eingeführten Teilsystemen wird Display teilt sich Display in die Teilsysteme, beziehungsweise in diesem Punkt Komponenten Website, UserClient und OwnerClient auf.
\paragraph{Website}
Hat die Aufgabe eine mithilfe eines üblichen Internetbrowsers darstellbare Webseite zu erstellen, wozu sie sich über das Interface GetProductInfo alle nötigen Informationen über die Produkte holt.
Außerdem ist sie der Eingangspunkt zum System, ein Benutzer, der über das Internet auf den Webshop zugreifen will, sich aber noch nicht als Kunde oder Betreiber authentifiziert hat, kommuniziert mit dieser Komponente des Systems.

\paragraph{OwnerClient}
Ist eine Spezialisierung von Website, die die Schnittstelle für den Betreiber des Systems darstellt. Mithilfe dieses Komponenten und der Interfaces ManageProducts zum ProductManagement, und dem Interface ManageOrders zum OrderManagement, ist es dem Betreiber möglich die Produkte beziehungsweise Bestellungen zu verwalten.

\paragraph{UserClient}
Ist ebenfalls eine Spezialisierung von Website, die die Schnittstelle zu einem Kunden darstellt. Mitfhilfe des Interfaces UserInteractions ist es dem Kunden möglich sich einzuloggen, Bestellungen zu tätigen und die eigenen Kundeninformationen zu bearbeiten.

\paragraph{ProductManagement}
Realisiert die Interfaces GetProductInfo und ManageProducts, die Website und OwnerClient benötigen. Benötigt allerdings dazu selbst ein Interface DatabaseInterface, das eine Schnittstelle zur Komponente DataManagement darstellt. ProductManagement ist für alle Funktionen die Produkte betreffen zuständig, also zum einen das Erstellen von Produktlisten und das Suchen nach speziellen Produkten, als auch die Verwaltung der einzelnen Produkte, was das Hinzufügen, Bearbeiten und Entfernen von Produkten beinhaltet.

\paragraph{UserManagement}
Realisiert das Interface UserInteractions und benötigt die Interfaces DatabaseInterface und MakeOrders zu DataManagement beziehungsweise OrderManagement. Ist für die Verwaltung der Kunden zuständig, ermöglicht den Kunden den Login ins System und stellt die Daten des Kunden bereit. Außerdem können Kunden über das Benutzermanagement Produkte zu einem Einkaufswagen zusammenstellen und bestellen. Auch das neue Erstellen von Kundenaccounts und das bearbeiten eines Kundenaccounts gehört zum Aufgabenbereich.

\paragraph{OrderManagement}
Stellt die Interfaces MakeOrders und ManageOrders zur Verfügung und benötigt selbst das Interface DatabaseInterface. Befasst sich mit der Verwaltung von Bestellungen, ermöglicht es Bestellungen aufzugeben, zu stornieren, eine PackingList zu drucken, ein Rechnungsschema zu definieren und mit diesem Rechnungen zu drucken.

\subsubsection{Komponenten - extern}

\paragraph{Database}
Stellt das Interface DatabaseInterface zur Verfügung. Es kann eine beliebige relationale Datenbank verwendet werden, die mit konventionellem SQL bedient werden kann. (Weiteres unter Hardware/Software Mapping)

\paragraph{Mailserver}
Stellt das Interface MailInterface zur Verfügung. Weiteres unter Hardware/Software Mapping.

\subsubsection{Interface Spezifikationen}
\includegraphics[scale=1]{DatabaseInterface.jpg}
\paragraph{sendSQLQuery}
Dieser Funktion wird eine Anfrage in der Datenbanksprache SQL übergeben, die die Datenbank dann ausführt.

\includegraphics[scale=1]{MailInterface.jpg}
\paragraph{sendMail}
Diese Funktion nimmt die Emailadresse des Absenders, das Passwort des Absenders, die Emailadresse des Empfängers und die Nachricht entgegen und schickt dann eine Email mit der Nachricht an den Empfänger.

\includegraphics[scale=1]{GetProductInfo.jpg}
\paragraph{getAllProducts}
Bekommt einen Parameter übergeben, der spezifiziert, wie die Produkte in der zurückgegebenen Liste sortiert sein sollen. Der Rückgabewert ist eine sortierte Liste aller verfügbaren Produkte.

\paragraph{getInformation}
Diese Funktion bekommt die Produktnummer eines bestimmten Produkts übergeben und gibt vorhandenen Informationen zu dem Produkt zurück, falls dieses existiert, andernfalls gibt sie null zurück.

\paragraph{searchProducts}
Bekommt den Namen eines Produkts, oder dessen Produktnummer übergeben und gibt das gesuchte Produkt zurück, falls dieses existiert, oder null falls dieses nicht existiert.

\includegraphics[scale=1]{ManageProducts.jpg}
\paragraph{addProduct}
Bekommt ein neues Produkt übergeben und speichert dieses in der Datenbank ab.

\paragraph{deleteProduct}
Bekommt eine Produktnummer übergeben und löscht das Produkt mit dieser Nummer aus der Datenbank.

\paragraph{editProduct}
Bekommt eine Produktnummer, sowie ein Produkt übergeben und speichert dieses Produkt unter der angegebenen Produktnummer ab, falls diese bereits existiert.

\includegraphics[scale=1]{ManageOrders}
\paragraph{attachTrackingId}
Bekommt als Parameter Bestellungsnummer und TrackinID übergeben. Fügt der Bestellung die TrackingID hinzu und sendet eine Info-Email an den Kunden, der die Bestellung aufgegeben hat.

\paragraph{cancelOrder}
Storniert die Bestellung mit der übergebenen Bestellungsnummer und sendet eine Info-Email an den Kunden.

\paragraph{confirmOrder}
Kennzeichnet die Bestellung mit der übergebenen Bestellungsnummer als bearbeitet und sendet eine Bestätigungsmail an den Kunden.

\paragraph{createInvoiceScheme}
Erzeugt ein Schema nach dem die Rechnungen erstellt werden sollen.

\paragraph{getOrder}
Gibt die Order mit der übergebenen Bestellungsnummer zurück, oder null, falls diese nicht existiert.

\paragraph{printInvoice}
Druckt eine Rechnung für die Bestellung, die die übergebene Bestellungsnummer hat.

\paragraph{printPackingList}
Druckt eine Packliste für die Bestellung mit der übergebenen Bestellungsnummer.

\includegraphics[scale=1]{MakeOrders.jpg}
\paragraph{cancelOrder}
Storniert die Bestellung, die die übergebenen Bestellungsnummer hat.

\paragraph{getOrders}
Gibt eine Liste der Bestellungen zurück, die der übergebene Benutzer aufgegeben hat.

\paragraph{makeOrder}
Speichert die übergebene Bestellung in der Datenbank und schickt eine Info-Email an den Betreiber, dass eine neue Bestellung eingegangen ist.

\includegraphics[scale=1]{UserInteractions.jpg}
\paragraph{addToShoppingCart}
Fügt das übergebene Produkt der ShoppingCart hinzu.

\paragraph{checkout}
Gibt eine Bestellung für die Produkte der ShoppingCart auf.

\paragraph{createUser}
Erstellt mit den übergebenen Werten einen neuen Kunden und speichert den neuen Kunden in der Datenbank ab.

\paragraph{deleteFromShoppingCart}
Löscht das übergebene Produkt aus der ShoppingCart.

\paragraph{deleteUser}
Löscht den übergebenen Kunden aus der Datenbank.

\paragraph{editUser}
Speichert den Kunden mit neuen Informationen in der Datenbank.

\paragraph{login}
Übernimmt einen Kundennamen und ein Passwort und loggt den Kunden in das System ein, wenn Kundenname und Passwort gültig sind.

\paragraph{logout}
Loggt den eingeloggten Kunden aus.

\subsubsection{Class Diagram}
\begin{figure}[H]
  \begin{adjustwidth}{-\oddsidemargin-1in}{-\rightmargin}
    \centering
    \includegraphics[scale=0.65]{ClassDiagram.jpg}
    \label{fig:fig1}
  \end{adjustwidth}
\end{figure}
Die Teilzerlegung als Class Diagram erfordert, dass die Subsysteme noch mehr zerlegt wird, da sonst das Class Diagram nicht vollständig, einfach und verständlich umgesetzt werden kann. Hierbei werden unter dem UserClient noch die Klassen Session und Shopping Cart hinzugefügt. Diese sollen die Verständigung zwischen den einzelnen Klassen erleichtern. Darüber hinaus wird die Klasse Data-Management als sehr abstrakte Datenbank gesehen, dafür müssen noch als Aufbau auf Data-Management die Klassen Produkt, User und Order erzeugt werden, da diese nur in der Datenbank vorhanden sind, aber für das Verständnis des Class Diagrams wichtig sind. \\
Die anderen Klassen lassen sich leicht vom Component Diagram ablesen und durch ihre notwendigen Funktionen vervollständigen, wie es in dem Class Diagram oben ist. Hierbei muss aber noch hinzugefügt werden, dass Data-Management als Datenbank verstanden werden muss. createGUI() ist im Diagramm auch eine Pseudo-Funktion, die den Aufbau der Seite im Browser veranschaulichen soll. Dies wird je nach Art des Zugreifenden anders aufgebaut und verändert. Beim OwnerClient wird mehr auf die Verwaltung und das Management der Produkte wert gelegt, während beim UserClient mehr wert darauf gelegt wird, dass die Produkte angezeigt werden und dass der User Produkte bestellen kann. Auch wird wenn man nicht Owner ist einem nur die Möglichkeit gegeben, dass sich entweder ein User einloggt oder ein neuer User einen Account erstellt um auf den Warenkorb zuzugreifen.

\subsection{Hardware/Software mapping}
Das Webshop wird hauptsächlich aus drei Hardware Komponenten bestehen: der Web Server, der Datenbank Server, und ein Mail Server. Der Web Server beinhaltet Teilsysteme UserManager, ProductManager, OrderManager. Aus Sicherheitsgründen wird die Datenbank auf einen anderen Server verlegt, worauf alle Komponenten im Webshop durch ein Interface zugriff haben.\\
\includegraphics[scale=0.5]{HardSoft.png}


\subsection{Management Persistenter Daten}
Alle wichtigen Daten, wie Produktdaten, Kundendaten und Bestellungen werden in einer Datenbank gespeichert und verwaltet. Zur Kommunikation zwischen den Teilsystemen werden die Datenstrukturen
\begin{itemize}
\item User (Kunde)
\item Product (Produkt)
\item Order (Bestellung)
\end{itemize}
verwendet, die alle wichtigen Informationen über die entsprechenden Objekte enthalten.


\subsection{Zugriffskontrolle und Sicherheit}
Durch die strikte Differenzierung zwischen Kunden und Betreiber ist es einem potenziellen Angreifer nicht möglich über einen Kundenaccount die Zugriffsrechte eines Betreibers zu erlangen. Des weiteren findet keine direkte Kommunikation zwischen Benutzer (sowohl Kunde, als auch Betreiber) und der zugrundeliegenden Datenbank statt. Diese wird durch die Zwischenebenen ProductManagement, UserManagement und OrderManagement getätigt, was einen Angriff auf diesem Wege (beispielsweise per SQL-Injection) erschwert.


\subsection{Globale Softwaresteuerung}
UserClient und OwnerClient stellen die Schnittstellen zum Kunden bzw. Betreiber dar.


\subsection{Randbedingungen}
\subsubsection{Systemstart/ende:}
Da das  System einen Webshop, also eine Webseite realisiert, die rund um die Uhr sieben Tage die Woche online ist, gibt es keine spezifischen Start oder Stop Prozeduren für das System.
\subsubsection{Systemfehler}
Sollte das System abstürzen, so genügt es sicherzustellen, dass die Datenbank wieder funktionstüchtig ist, und das System auf dem Server gestartet wird, also die Webseite aufbaut. Die Datenbank stellt sicher, dass alle Transaktionen die zum Zeitpunkt des Systemabsturz liefen, zunächst rückgängig gemacht und dann neu ausgeführt werden.


\section*{Testing}

Das System wird per Bottom-Up Strategie auf seine Integrität überprüft, dabei werden die Subsysteme in verschiedenen Kombinationen auf ihre zusammenhängende Lauffähigkeit überprüft.\\
Bei der Bottom-Up Strategie werden zuerst die untersten Kombinationen überprüft und das System wird langsam nach oben überprüft bis alles überprüft wurde. Im nachfolgenden kommen die wichtigsten Test-Cases zu dem Webshop-System:
\renewcommand{\arraystretch}{1.5}
\subsection*{UserTest()}
\begin{tabularx}{\linewidth}{lX}
\hline
\textit{Test-case identifier} & UserTest()\\
\textit{Feature to be tested} & Erstellt einen User in der Datenbank, editiert diesen und löscht ihn danach wieder.\\
\textit{Feature Pass/Fail Criteria} & Der Test erfüllt die Bedingungen, falls alle Methoden ausgeführt werden können, ohne dabei einen Fehler zu erzeugen.\\
\textit{Means of control} & Die UserTest() Methode wird gestartet über die Testkomponente Test, die dafür extra erstellt wird.\\
\textit{Data} & User-Daten für das erstellen des Users wird in der Methode UserTest() generiert und übergeben, eben gleiches gilt für das editieren.\\
\textit{Special requirements} & User-Management und Data-Management-Komponente.\\
\hline
\end{tabularx}
\subsection*{ProductTest()}
\begin{tabularx}{\linewidth}{lX}
\hline
\textit{Test-case identifier} & ProductTest()\\
\textit{Feature to be tested} & Erstellt ein Produkt in der Datenbank, gibt alle Produkte aus, editiert dieses, gibt dieses aus, sucht dieses und löscht es dann wieder.\\
\textit{Feature Pass/Fail Criteria} & Der Test erfüllt die Bedingungen, falls alle Methoden ausgeführt werden können, ohne dabei einen Fehler zu erzeugen.\\
\textit{Means of control} & Die ProductTest() Methode wird gestartet über die Testkomponente Test, die dafür extra erstellt wird.\\
\textit{Data} & Produkt-Daten für das erstellen des Produktes wird in der Methode ProductTest() generiert und übergeben, eben gleiches gilt für das editieren. Die ausgegebenen Daten werden mit vorhandenen Daten verglichen und falls nicht identisch wird ein Fehler ausgegeben.\\
\textit{Special requirements} & Product-Management und Data-Management-Komponente.\\
\hline
\end{tabularx}
\subsection*{OrderTest()}
\begin{tabularx}{\linewidth}{lX}
\hline
\textit{Test-case identifier} & OrderTest()\\
\textit{Feature to be tested} & Erstellt eine Order in der Datenbank, sichert dieses, editiert dieses, gibt dieses aus und löscht dieses danach.\\
\textit{Feature Pass/Fail Criteria} & Der Test erfüllt die Bedingungen, falls alle Methoden ausgeführt werden können, ohne dabei einen Fehler zu erzeugen.\\
\textit{Means of control} & Die OrderTest() Methode wird gestartet über die Testkomponente Test, die dafür extra erstellt wird.\\
\textit{Data} & Order-Daten für das erstellen des Produktes wird in der Methode OrderTest() generiert und übergeben, eben gleiches gilt für das editieren. Die ausgegebenen Daten werden mit vorhandenen Daten verglichen und falls nicht identisch wird ein Fehler ausgegeben. Überprüft außerdem, ob die Email and den Owner und an den User geschickt wurde.\\
\textit{Special requirements} & Order-Management und Data-Management-Komponente.\\
\hline
\end{tabularx}
\subsection*{ShoppingCartTest()}
\begin{tabularx}{\linewidth}{lX}
\hline
\textit{Test-case identifier} & ShoppingCartTest()\\
\textit{Feature to be tested} & Fügt Produkte zum Warenkorb hinzu, gibt Warenkorb-Inhalt aus, löscht Produkte aus dem Warenkorb und bestellt ( CheckOut ).\\
\textit{Feature Pass/Fail Criteria} & Der Test erfüllt die Bedingungen, falls alle Methoden ausgeführt werden können, ohne dabei einen Fehler zu erzeugen.\\
\textit{Means of control} & Die ShoppingCartTest() Methode wird gestartet über die Testkomponente Test, die dafür extra erstellt wird.\\
\textit{Data} & Produkte sollten schon in der Datenbank vorhanden sein, benutzt diese zum hinzufügen und ausgeben, dieses wird verglichen mit soll Werten, gibt falls Falsch Fehler aus. Bestellt, überprüft dabei ob die Order in der Datenbank danach vorhanden ist und überprüft, ob die Emails an Owner und User geschickt wurden.\\
\textit{Special requirements} & Shopping Cart, Order-Management und Data-Management-Komponente.\\
\hline
\end{tabularx}
\subsection*{OwnerClientTest()}
\begin{tabularx}{\linewidth}{lX}
\hline
\textit{Test-case identifier} & OwnerClientTest()\\
\textit{Feature to be tested} & Logt sich auf dem OwnerClient ein, baut Seite auf, erstellt Produkt, erstellt Order, gibt Produkt aus, gibt Order aus, löscht Produkt, löscht Order und logt sich wieder aus.\\
\textit{Feature Pass/Fail Criteria} & Der Test erfüllt die Bedingungen, falls alle Methoden ausgeführt werden können, ohne dabei einen Fehler zu erzeugen.\\
\textit{Means of control} & Die OwnerClientTest() Methode wird gestartet über die Testkomponente Test, die dafür extra erstellt wird.\\
\textit{Data} & Produkt-Daten für das Erstellen des Produktes und die Order-Daten für das Erstellen der Order wird in der Methode OwnerClientTest() generiert und übergeben, eben gleiches gilt für das editieren. Die ausgegebenen Daten werden mit vorhandenen Daten verglichen und falls nicht identisch wird ein Fehler ausgegeben. Überprüft außerdem, ob die Email and den Owner und an den User geschickt wurde.\\
\textit{Special requirements} & OwnerClient-, Produkt-Management-, Order-Management und Data-Management-Komponente.\\
\hline
\end{tabularx}
\subsection*{UserClientTest()}
\begin{tabularx}{\linewidth}{lX}
\hline
\textit{Test-case identifier} & UserClientTest()\\
\textit{Feature to be tested} & Logt einen Test-User, welcher in der Datenbanken vorhanden ist, ein, baut Seite auf, fügt Produkt Warenkorb hinzu, löscht Produkte aus Warenkorb, logt den User aus.\\
\textit{Feature Pass/Fail Criteria} & Der Test erfüllt die Bedingungen, falls alle Methoden ausgeführt werden können, ohne dabei einen Fehler zu erzeugen.\\
\textit{Means of control} & Die UserClientTest() Methode wird gestartet über die Testkomponente Test, die dafür extra erstellt wird.\\
\textit{Data} & Test-User-Daten und Produkt-Daten müssen schon in der Datenbank vorhanden sein.\\
\textit{Special requirements} & UserClient-, Produkt-Management-, Order-Management und Data-Management-Komponente.\\
\hline
\end{tabularx}


\end{document}